Modem high-speed communication systems over a twisted pair (e.g. of copper lines) or other communication lines usually use crosstalk cancellation, which reduces substantially the stationary noise at the input of the receiver. This crosstalk cancellation is also referred to as vectoring. Thus, non-stationary noise becomes one of the main noise components remaining after crosstalk cancellation. Examples of non-stationary noise are narrow-band and wide-band RFI (Radio frequency interference), operation of other broadband communication systems, such as PLC (power line communication), or unexpected changes in channel characteristics, such as disordered disconnect of lines in a cable binder including the twisted pair. Various approaches have been defined to protect against these noise components.
The Robust Management Channel (RMC) is defined in communication systems to support management procedures that have to be extremely reliable, such as simultaneous changing of modem configuration at both sides of a communication line. The RMC is also used to recover a data channel over the communication line when its signal-to-noise ratio (SNR) margin drops so low that no data communication is possible. In G.fast (ITU-T G.9701, as approved Dec. 5, 2014, shortly referred to as G.9701 12/14 or G.fast herein), that uses Discrete Multi-Tone (DMT) modulation, RMC is defined to operate on a selected set of tones with high SNR margin, which provides much higher reliability of RMC than it is set for data. In other words, for the RMC a higher SNR margin than for other channels, for example for data channels, are provided. Furthermore, for the RMC channel a forward error correction (FEC) may be implemented, e.g. a FEC which is set to parameters allowing maximum protection. Thus, RMC can be used to recover data channel when the noise becomes too high for implementation of usual noise adaptation procedures over data channel, such as bit swapping and seamless rate adaptation (SRA).
In the following description, terms used may have a meaning as defined in G.fast (ITU-T G.9701) as approved Dec. 5, 2014, unless noted otherwise herein. Implementation of various components like transmitters, receivers or transceivers (combination of transmitter and receiver) may be as defined in G.fast.
The most important use of RMC in G.fast is for a Fast Rate Adaptation (FRA) procedure. When receiver detects a persistent failure of data transfer, it initiates FRA that can quickly recover the failed data channel via short commands sent over RMC. This however, requires RMC channel to be operable under noise conditions that data channel cannot withstand.
The RMC itself, however, can also be impaired by noise, which may reduce the SNR margin on RMC tones and even make these tones unavailable to information transfer. When the RMC has a reduced SNR margin or is disrupted, there is a need to recover it first in the aim to then get data channel back to work using e.g. the FRA procedure. A typical example of this is a scenario when a customer premises equipment (CPE) in a vectored system is disorderly disconnected or other changes in a transmission channels happened unexpectedly. Due to vectoring, changes in the channel may cause a drop of SNR so substantial that not only data channel, but also the RMC may fail. Therefore, a mechanism is needed to recover RMC when noise conditions are severe.
An RMC parameter adjustment (RPA) procedure is a part of the online reconfiguration (OLR) package defined by G.fast. It allows to recover the SNR margin by a RMC modification of the RMC tone set (RTS) and bit loading on the RMC tones, i.e. updating which tones shall be used for RMC and their bit loading. The RPA request is issued by the RMC receiver when robustness of the RMC is reduced, which is determined by applying a certain RPA criteria, such as loss of SNR margin on RMC tones. Upon detection that the RPA criteria is met, the receiver communicates to the far-end transmitter at the other end of the communication line the needed changes in the RTS and its bit loading, as well as the exact time of the change via the embedded overhead channel (eoc) of the opposite transmission direction, which is a part of the data channel. This RPA mechanism can operate only if noise damages only one direction of transmission, while in the other direction the eoc operates properly.
In case of a severe SNR margin drop at the receiver, so that neither data nor RMC communication can survive in a particular direction, the FRA cannot be used to recover data channel, but RPA procedure can still recover the RMC if the eoc is operable in the opposite direction. The expected time necessary to recover the RMC is about 100 ms. After RMC is recovered, the FRA can be applied to restore data communication and further SRA can adapt the system to new noise conditions and restore its performance.
The problem with this conventional solution occurs if the data/eoc channel in the opposite direction is also down under the impact of the noise: even if the RMC in the opposite direction is still alive, there is currently no means defined to use this alive RMC for recovering the system.
Besides, the conventional solutions do not address specifically the case of RMC failure in one transmission direction. In this case a synchronous change of RMC parameters by both transmitter and receiver connected to the line is not necessary (because the RMC is not functional anyway)